fix(agentflow): condition node leaks parallel branches when an output fans out to multiple nodes#6532
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the determineNodesToIgnore function in buildAgentflow.ts to use edges.filter instead of edges.find. This ensures that all matching edges for an unfulfilled condition are collected and ignored, preventing parallel branches sharing the same output handle from leaking. There are no review comments, so I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
…ultiple nodes
In AgentFlow v2, `determineNodesToIgnore` used `edges.find()` to locate the
edge for each unfulfilled condition output. When a single condition output
fans out to multiple target nodes (parallel branches sharing the same
`-output-${index}` handle), only the first target was added to the ignore
list. The remaining parallel nodes were never gated and leaked into other
branches — e.g. selecting the else branch would still execute one of the
nodes wired to the matched branch.
Switch to `edges.filter()` so every target connected to an unfulfilled
output is ignored.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
b9fb40d to
20183ea
Compare
|
@jocelynlin-wd @0xi4o @HenryHengZJ @yau-wd |
What & Why
In AgentFlow v2, when a single Condition output is connected to two or more nodes (parallel branches), selecting a different branch still executes one of the nodes wired to the unselected branch.
Root cause
determineNodesToIgnoreinpackages/server/src/utils/buildAgentflow.tsusesedges.find()to locate the edge for each unfulfilled condition output:find()returns only the first matching edge. When one output (-output-${index}) fans out to multiple targets, only the first target is added toignoreNodeIds. Downstream, child nodes are executed unless they are in that list (if (ignoreNodeIds.includes(childId)) continue), so the remaining parallel targets are never gated and leak into other branches.Because the leaked node depends on edge ordering, the same bug also surfaces as the opposite symptom (a matched branch appearing to "stop"), which matches the reports in the linked issues.
Reproduction
output-0→ LLM A and LLM B (two edges on the same output)output-1→ LLM CExpected: selecting
output-1runs only LLM C.Actual: LLM C and one of LLM A / LLM B both run.
Minimal flow JSON used to reproduce:
Bug Test Agents.json
🎥 Before (bug) — selecting
output-1wrongly runs anoutput-0node too:Fix
Use
edges.filter()and ignore every target connected to an unfulfilled output:🎥 After (fixed) — selecting
output-1runs only the correct node:Related issues
Notes
find()pattern exists in the legacy v1 IfElse path (packages/server/src/utils/index.ts), but it involves a different node type / routing model and is intentionally left out of this PR.